Schema Models
3. Schema Models
In this project, Prisma’s schema models are defined in schema.prisma
. Each model represents a table in the database. Below, we detail the purpose and structure of each model.
Model: CasbinRule
Purpose
The CasbinRule
model is used to support Casbin-based access control in the application. Casbin is a popular library for handling access control lists (ACLs), and storing rules in the database allows for dynamic policy management.
Fields Explanation
id
(Int): Primary key, auto-incremented for unique identification.ptype
(String): Indicates the policy type for the Casbin rule, required for distinguishing rule types.v0
,v1
,v2
,v3
,v4
,v5
(String?): Optional fields to represent rule attributes, which can include subject, object, action, etc., as defined by Casbin’s policy model.
Table Mapping
The CasbinRule
model is mapped to the casbin_rule
table in the database:
model CasbinRule {
id Int @id @default(autoincrement())
ptype String
v0 String?
v1 String?
v2 String?
v3 String?
v4 String?
v5 String?
@@map("casbin_rule")
}
Reasoning for Structure
Each field corresponds to attributes commonly used in access control policies. By using optional fields, this schema supports various policy models and enables flexible rule management.
Model: User
Purpose
The User
model stores user-related data, including login credentials, profile information, and organization relationships.
Fields Explanation
id
(String): Primary key, generated as a UUID for global uniqueness.email
(String): Unique field to store the user’s email.password
(String): Stores the hashed password of the user.name
(String?): Optional field for the user’s display name.created_at
(DateTime): Automatically set timestamp indicating when the user was created.updated_at
(DateTime): Automatically updated timestamp whenever the user record is modified.
Relation to Other Models
The User
model contains a relationship to the OrganisationOnUser
model (not fully shown here), which maps users to organizations they belong to.
model User {
id String @id @default(uuid())
email String @unique
password String
name String?
created_at DateTime @default(now())
updated_at DateTime @updatedAt
}
Reasoning for Structure
- UUID Primary Key: Provides a globally unique identifier, avoiding potential conflicts.
- Auto-updating Timestamps: Ensures the data is always consistent with when the user account was created or last modified.
- Email as Unique Field: Prevents duplicate accounts and simplifies authentication.